Database applications interact with a database server by sending to the database server commands that conform to a language supported by the database server. The Structured Query Language (SQL) is a popular language supported by many database servers. The commands sent by database applications to database servers that support SQL are referred to herein as SQL commands.
SQL may be used to specify a wide variety of operations, including operations that could compromise the integrity of the database against which the operations are performed. Therefore, it is important for database application developers to design database applications in a manner that does not allow users of their applications to request operations that the application developers do not intend.
Under certain conditions, a database application may send to a database server a SQL command that requests an operation that the application was not designed to request. This scenario may occur, for example, if some or all of the text of the SQL command sent by the application is the result of a “SQL injection”.
A “SQL injection” is the input and eventual execution of a syntactically meaningful fragment of SQL through an ordinary user data entry mechanism. Commonly, the term “SQL injection” is reserved for such inputs which are not anticipated by the application developers to be SQL fragments.
A “SQL injection threat” is a SQL injection that acquires access to the database and its facilities, which access was not intended to be granted. Such an injection is a “threat” because the unintended access can be used to damage or subvert the database. A SQL injection may be benign, understood, and intended by the application designer or “malignant” in the sense that the application designer did not intend for the injection to exist.
In many situations, SQL injection threats exist because application developers do not realize that a particular portion of their application is vulnerable. A portion of an application that is vulnerable to SQL injection is referred to herein as a “vulnerable site”. Due to the potential damage that may result from a SQL injection, it is desirable to provide a mechanism that detects and identifies vulnerable sites within database applications.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.